Huh, why is the resolve && bit needed here?

Eslint can't tell that resolve will always be assigned (since it is assigned inside the Promise(() => {}) function) so it complains that resolve might be undefined here.

The && is just an old habit I picked up from previous JS codebases I worked on. This code is roughly equivalent to:

// `!!` coerces resolve into a boolean, which is what the && is doing implicitly above
// !!undefined => 0
// !!(() => {})  => true  -- this works with any function
if (!!resolve) {  resolve(true) }

Since we are using ecma2020 features, I could also change it to resolve?.(true) by using the optional chaining operator.

I'm don't think there is an equivalent to the ! typescript operator (not null/undefined) in javascript, so if we want to make the linter happy without disabling it we'll need some of check (&&/if) or optional chaining.

If we want the code to be more explicit and not rely on quirks like coercion or newer features like ?, then I would probably go with if (resolve !== undefined) { resolve(true) }

I went ahead and changed it to the explicit if (resolve !== undefined) { resolve(true) } check in 06a283d. Let me know if you would prefer the optional chaining option, or something else entirely.

My thinking here was more that if this is ever undefined, I'd want us to error, rather than just silently not call resolve the way we would given a construct like this. Tracking down failures to resolve are super painful :p

I was sure I replied to this over the weekend, but I must have forgotten to click on comment and lost the previous message 😢.

You raised a good point, I was initially just trying to bypass this limitation of the type system (since the callback to promises is synchronous so it's not possible for resolve to ever be undefined with the current code. But I hadn't considered that future code changes could lead to frustrating troubleshooting.

The executor is called synchronously (as soon as the Promise is constructed) with the resolveFunc and rejectFunc functions as arguments. (https://developer.mozilla.org/enUS/docs/Web/JavaScript/Reference/Global_Objects/Promise/Promise)

I'll revert the code back to what it was before.

/**
 * SAFETY: Since the Promise constructor (executor) is ran synchronously on Promise creation
 * both `resolve` and `reject` will not be `undefined` when returned from this function.
 * https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/Promise
  * @returns {Promise & { resolve: (value: unkown) => void, reject: (reason?: any) => void}
 */
function deferrablePromise() {
  let resolve;
  let reject;
  const promise = new Promise((rs, rj) => {
    resolve = thisResolve;
    reject = thisReject;
  });
  return Object.assign(promise, { resolve, reject });
}
/* ... */
fetch_done = deferrablePromise(); // Create a promise that holds it's own resolve function
/* ... */ 
fetch_done.resolve(true)

That seems reasonable to me!